The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
As the number of network hosts increases, fewer and fewer network addresses are available to uniquely identify new hosts. For example, in the context of the Internet, host network addresses conforming to version 4 of the Internet Protocol (“IPv4 addresses”) are an increasingly scarce commodity, and it is desirable to conserve them.
In one approach, conservation is implemented by assigning private, reusable IP addresses to hosts in a local area network that are logically located behind a network device, such as a router, that performs network address translation (NAT). However, NAT devices often interfere with the correct operation of some higher-level protocols that encode IP information above the network layer, such as File Transfer Protocol (FTP). Thus, for a particular network, a first subset of clients may need to interact with external FTP servers, and therefore may need public routable addresses, whereas a second subset of clients may suffice with private addresses that are known behind a NAT device but that are not publicly routable. Managing these different needs is a challenge if static network addresses are assigned, but the needs of a particular client then change.
Some networks use Dynamic Host Control Protocol (DHCP) for assigning network addresses. DHCP is defined in IETF Request for Comments (RFC) 2131 and in RFC 2132. In networks with DHCP, the conventional solution to the problem of address scarcity is to create DHCP reservations for clients requiring public addresses, and to assign private address leases through standard DHCP mechanisms. This solution is problematic for several reasons. Reservations do not have expiration times, so it is difficult to recover public IP addresses for re-use. Programmatic interfaces to DHCP servers are proprietary or non-existent, complicating the problem of managing the reservations.
Conventional DHCP operation is performed in a network having one or more DHCP servers, which are hosted at arbitrary locations in the network, and one or more DHCP clients that are hosted at respective client devices in the network, such as workstations or PCs. Not all the DHCP servers may be able to provide a network address to a particular client. Generally, each DHCP server is responsible for assigning network addresses within specified ranges associated with “scopes” of clients. If a DHCP server receives a request from a gateway that is coupled to clients that are outside the scopes configured on that DHCP server, or if there are no addresses available within the scope that the DHCP server selects for the request, then that DHCP server does not respond to the request. DHCP servers usually determine whether a received request should be offered an IP address within a particular scope by examining the value of the “giaddr” field.
A DHCP relay agent may be communicatively coupled to or hosted by a gateway, which is often the default gateway with respect to a particular client device. When a client device needs a network address, such as upon boot-up or restart, the client device broadcasts a DHCP Discover message, which is received by its DHCP relay agent. The relay agent forwards the Discover message to one or more DHCP servers that can potentially provide addresses for the client, and provides the network address of interface on which the relay received the request in the gateway address (“giaddr”) field of the forwarded message.
One or more of the DHCP servers responsible for the scope associated with the gateway and client may respond with Offer messages that offer a lease for an available network address to the client. The relay agent relays each offer to the client. The client selects one of the offers and requests it from the DHCP server that offered it, via the relay agent. If the DHCP Server positively acknowledges this request, the client can determine that it has succeeded in obtaining the associated address until expiration of the lease.
One past variation on this approach involves a smart-relay function. In smart relaying, primary and secondary address values are configured on the interface of a DHCP relay agent through which the agent receives broadcast DHCP requests. If a client cannot get a lease when the primary address is used as the “giaddr” field value, then the DHCP relay agent sends another DHCP request that uses the secondary interface address value for the “giaddr” field. Thus, the smart-relay function provides an overflow feature, which allows clients to get leases from the overflow scope if no leases are available on the primary scope. No policy decision-making is involved. The smart-relay function is most useful in networks having a large number of clients where it is appropriate to shift to a secondary scope if the first is unavailable.
Another approach to policy-based scope selection uses the contents of DHCP Option 82, which is inserted by the DHCP relay agent, to override the value of the “giaddr” field for the purpose of scope assignment. DHCP Option 82 is described in IETF RFC 3046. This is a viable approach when the following three conditions hold: 1) the DHCP relay agent has the knowledge of, for example, the user identity to insert in Option 82 to drive the scope selection; 2) the DHCP server supports scope determination through the contents of Option 82 instead of the value of “giaddr”; and 3) the DHCP server has programmatic access to the source of lease assignment policy decisions. In many cases, however, one or more of these three conditions are not met and another approach is indicated.
Based on the foregoing, there is a clear need for an improved way to provide address conservation in a network.
There is a specific need for a way to assign network addresses from a plurality of different scopes, based on external policy decisions. For example, a network administrator may wish to enforce a policy that assigns private addresses whenever possible, and public addresses only when necessary.